So yesterday we had a really nice meeting with few french Debian folks. Luk and Ralf were visiting us, so we went at Prosper's for some meat and wine (and Aberlour). We were a bit too much to be able to speak to everybody (so mainly there were two 6-packs of people), but it was fine anyway. Though, the main point of the evening was that some (most?) teams in Debian are really (*really*) understaffed, and it might become problematic in the near future (like now). For example, from what I understood:

• debian-x has one active contributor
• pkg-xfce has one active contributor
• evolution has one de factor contributor
• pkg-gnome is better since Josselin had some help, but it's still not perfect
• d-i has only one active contributor
• libc has only one active contributor

I don't know the state of other teams, but it doesn't really look fine for the incoming freeze. So if you want to give some help, even if you're not yet technical enough, feel free to offer it to the teams above. Usually, starting with just using the package is enough. If you use it, you want it well-maintained, and there _are_ stuff to do to which don't require large technical knowledge, and the (few) active contributor will be happy to have some help and point you to what you can do. If you want to give some time to Debian, before filing some ITPs (even if you'd really like to have that package you use everyday), check if you can't do something for those above teams (and others which might need help too, like release team or kernel). Oh, and don't be scared, working on Debian is fun. It's time consuming, but it's rewarding. Don't let it become not fun.

Over the last few days I have worked for some hours on packaging the last dependency of GNOME Shell that was missing in Debian: gjs. That work has been sponsored by Collabora, along with the work required to package GNOME Shell itself. I was very impressed by the time it took for FTP Masters and Assistants to deal with the new packages - it only took a couple days for each; kudos! What this all means is that you can now easily test GNOME Shell, and even make it your default environment on a Debian unstable system, by just installing the gnome-shell package. As I expected, some people have been having trouble with the new package, but the general feedback has been fairly positive. If the README.Debian package doesn t help you with your specific issue, do take the time to file a bug report! By the way, thanks go to Joss, for his work on dh_girepository, and for him, and Sebastian Dr ge for their work on creating the new GObject Introspection policy.

So, Waldi filed #545032, arguing the udev rules shipped in devicekit-disks are broken. He even added a conflict in dmsetup because of that. Whenever you ask him about this issue, the only things he answers are:

• The rules are broken and they need to be removed.
• The information is already available in other variables.

It would be nice if all of this was true, but:

• There is no explanation about how and why these rules could actually break anything.
• The information is not available in other variables, apart from a couple of trivial things. Or maybe it is, but since all that udev crap has absolutely zero documentation, there is no way to know how it is available.

The result: GNOME is currently not installable on a system with LVM. There is no foreseeable possibility to fix that. Great. Thanks.

---

I can t say I m surprised, but I m still appalled by reading, again, a completely out-of-reality polemic about a leader of the Free software community being called sexist (among other nice names), after an innocent and random word used in a talk. Oh noes! Serving in the navy will hurt! It s often that you hear jokes or references picturing French as arrogant, Italians as womanizers, geeks as bearded and smelling under the arms, sailors as gay, et c tera. It s called a clich , and it helps people understand each other because it s part of the collective imagination. If you insert a reference to an Italian in a speech about womanizers, it helps picturing the clich of a guy in a black Armani suit, wearing sunglasses and using gomina. It doesn t mean you think Italians are like this, and if it ever convinces someone that they are so, it means that someone really had trouble using the thing she calls brain to begin with. The same goes for a talk about people not being familiar to computers, that is using women as a clich . When you look for a picture in your mind of someone who has trouble with using computers, what do you find? A granny fighting with her keyboard which keys are not in alphabetical order, or a busty blonde following with her eyes each movement of the mouse cursor. It s only natural to use these pictures as a ground for communication, and it doesn t mean you think bad of grannies or busty blondes. And if, because of that or of anything else, some people end up thinking that women can t use a computer, or that they are not equal to men in this regard, these people are the sexist ones. Not the guy who drew that picture in a magazine you read 10 years ago and forgot since, nor the one using it as a reference. My intolerance is worth more than yours And instead of actually focusing on educating or slapping those people, some of us are conducting a witch hunt, in which anyone implying the very existence of different categories of people, called men and women, regardless of his merits or opinions, is called a sexist and has stones thrown to him on several public fora. This is not acceptable. Do not let your speech be dictated by intolerance. If you apply the same reasoning to anyone that could be possibly hurt, in a completely literal and simplistic analysis of the speech, you can stop right now using any kind of metaphor, idiomatic expression or proverb. All that remains is a poor, sterilized speech. And when the speech is poor, the ideas get poorer as well. Imagine what would a complete stranger reading those blogs understand. She would surely picture hackers as a completely misogynistic community in which people only talk about women (whether it is for sexist jokes or for rhetorical discussions about them) and never talk with them. Which would be utterly wrong, since hackers (and geeks in general) are on the contrary open-minded and friendly to feminism, compared to the rest of the population of course, except for the OMG OMG it s a woman! We need to be nice!!! kind. And this is actually the reasoning that hides behind all this insane RMS and Mark Shuttleworth are sexist trolls. The picture they are giving of women are that of fragile little things that need to be protected against any attack of all these evil misogynist bearded geeks. Pretty ironical for people who claim fighting for gender equality, isn t it? Questioning the unquestionable Frankly, RMS and Mark are among the people I trust the less in the community, but I don t need to paint them as misogynists for that. Look at what they say instead of how they say it: one is an intolerant man who used to be a visionary but turned his principles into dogma; the other has seen the light and behaves as if he was the savior of Free software. I d prefer if we questioned their vision and leadership based on their ideas and actions, not on distorted ways to interpret what they say based on a few people s neuroses. Or, to say it shorter: dudes, get a life.

In my haste to fix #545254, I have uploaded nautilus 2.28.0 a bit too early. If you have not upgraded yet, please don t install 2.28.0-1! If you have already upgraded, you should install 2.28.0-2 as soon as it is available, and then remove any ~/.nautilus/metafiles/migrated-to-gvfs files. This way you will find back your metadata (icon positions on the desktop, window sizes, emblems ) at the next login. Sorry for the inconvenience.

Here are a few hints if you want your reports to be treated more promptly. When testing fails, try unstable If you are running testing, not all bug reports are interesting. More specifically, the relevant ones are about insufficient dependencies that let slip into testing a non-working combination of packages. Think of the I upgraded foo, then bar broke category. Otherwise, the reason why reportbug looks for newer versions of a package in unstable is that, in most cases, the bug is fixed in unstable. If you can, always try the unstable version before reporting the bug. Report bugs against the failing package This is related to printing in a GNOME program, so I report this against libgnomeprint. Always file reports against the failing program. If there is a library involved, reportbug will include the necessary information so that the maintainer can easily reassign. If you re not sure of the affected package, use a metapackage (for example, gnome for GNOME-related packages). Do not second-guess the origin of the bug After upgrading libfoo, bar starts crashing, so I m reporting it against libfoo. Unless you can tell which function is at fault and how this is ABI breakage, you should report the bug against the program that crashes. The program s maintainer will reassign if needed, and will hit the library s maintainer with a hammer if needed. Don t forget to explain what s wrong The frobniz in libfrob is broken, you should change /usr/share/libfrob/blah line 13 to something else. I don t know what libfrob is about, but I have some problems that look frobniz-related. Do not second-guess, always start explaining what bug you are seeing first. Your attempts at investigating it can be interesting, but don t forget to explain what bug lead you on investigating. What is the use case we should cover? I m trying to do that with your package and it looks extremely complicated/doesn t work as expected/fails miserably. Your package is clearly broken! If your attempts to do something that should be trivial, given the purpose of the package, fail, then you are probably looking at the problem at the wrong angle. There may be a much simpler, though radically different, way to do what you are trying to achieve. In these situations, always include in your report what you are trying to do and why you want to do it. strace is not a general-purpose debugging tool Whether you observe a crash, a deadlock or a livelock, strace is not the tool that will give us information. The only thing you do by adding a strace log to the bug report is making it unreadable with its thousands of lines of output. For the specific cases that require strace for debugging, these traces are welcome but if you re not sure, don t attach them. The developers will ask them for you. Otherwise, the general-purpose debugging tool is gdb. Use reportbug There is a good reason why some packages include bug control files and scripts. Use a reporting tool that takes them into account. Unless you are requesting an enhancement, always use reportbug. Please avoid reportbug-ng since it only provides parts of the required information.

Seen on Slashdot: a large discussion forum site hacked through its backups. I had seen this coming. And it s just the beginning, you can expect this to be a major attack vector in the next years. Until people understand it s not possible to secure data without securing the network.

Due to the repeated tendency of our friends of the MPAA beloved government to create laws that turn computer and Internet users into criminals, I m considering to shutdown any kind of non-encrypted communications that I initiate from France. Therefore, I m looking for cheap dedicated hosting in an Internet-friendly country, in a way similar to what we have here with OVH or Iliad. My requirements are:

• low ping times from France
• high bandwidth (100 Mbits/s would be nice)
• 100 GB of RAID disk space

I m fine with blades, but not with virtual hosting. Suggestions are welcome. I m currently considering hosting solutions in the Netherlands, but I d appreciate some advice.

Up to lenny, our GNOME desktop lacks a bit branding. We used to have the splash screen but it doesn t show up anymore, so that only leaves the background. It has several times been requested to put a bit of branding in the menu, as most distributions do, and this has been in my mind for a while. I have uploaded a first attempt to unstable. Since I didn t want the branding to be too intrusive, I used the swirl foot logo of the pkg-gnome page. So far, the reactions haven t been very enthusiastic, that s why I m writing here. Any change generates an amount of grumpiness, and it s hard to distinguish what s caused by the mere fact that something broke people s habits, and what s really changed for the bad. This is why I have set up a little poll where users are welcome to voice their opinion. What should we set as the main menu icon?

• The good old GNOME foot icon
• The Debian swirl icon
• The swirl foot icon

I also welcome proposals for some other icon that would be better for this place. Actually, that would be my favorite option if I had something to propose, as I m not enthusiastic about any of the available ones. Time to be creative! So now is the time to express your preferences. If you have comments, please put them in the blog entry, not in the poll page. EDIT : I found that some opacity settings in the SVG I used for the swirl foot icon were completely wrong. Here is a new version, taking account what has been proposed in the comments:

• 

The gnome-power-manager developers like clean code. Actually, more than clean code: code that will not generate a single nitpicking warning. The package builds with the following C compiler flags:

-Werror -Wcast-align -Wno-uninitialized -Wall -Wformat-security

Sometimes the compiler is more clever than the coder On the SPARC architecture, -Wcast-align really starts to mean something. Unlike most other architectures, any alignment error on here will leave you gather your teeth spread on the floor after you ve been hit by a SIGBUS. It tries to catch at build time alignment errors resulting from a cast between pointers to different types. Together with -Werror, it triggered a first FTBFS bug. The error occured on the following code:

        if (XRRGetOutputProperty (brightness->priv->dpy, output, brightness->priv->backlight,
                                  0, 4, False, False, None,
                                  &actual_type, &actual_format,
                                  &nitems, &bytes_after,  ) != Success)  
                egg_debug ("failed to get property");
                return FALSE;
         
        if (actual_type == XA_INTEGER && nitems == 1 && actual_format == 32)  
                *cur = *((int *) prop);
                ret = TRUE;
         
        XFree (prop);
        return ret;

More precisely, the error occurs when casting prop (which is an array of pointers) into an int *. The compiler is clearly right. The alignment requirements are different for a pointer and an integer; therefore, casting a pointer to a pointer into a pointer to an integer will always work, but dereferencing the pointer later will possibly cause a crash. Turning this expression into a memcpy leads to code that should always work. Lesson learned: do not design APIs where an array of pointers can actually store integers. Have you ever heard of opaque structures? and sometimes it is not This was not enough and a second FTBFS bug showed up. Here, the error happens in the following code:

static inline GstBuffer *
gst_buffer_ref (GstBuffer * buf)
 
  /* not using a macro here because gcc-4.1 will complain
   * if the return value isn't used (because of the cast) */
  return (GstBuffer *) gst_mini_object_ref (GST_MINI_OBJECT_CAST (buf));
 

GstBuffer is a structure which contains a GstMiniObject at the beginning. Therefore, you conduct operations on the GstMiniObject through a mere cast. The first cast (GstBuffer GstMiniObject) is fine, but in the second cast (GstMiniObject GstBuffer), the compiler suspects a problem, since the alignment requirements on GstBuffer are stronger than those on GstMiniObject. The compiler is wrong because it didn t read the API documentation; otherwise, it would have known that gst_mini_object_ref can only return NULL or its argument, which means there can t be any loss of alignment. Since there are no function attributes to express such complex things, we are still forced to rely on the developer having correctly read the documentation. Way to go, compiler. Lesson learned: there are good reasons why some warnings are not part of -Wall. Especially, it is dubious to use them with -Werror. Does anyone know whether it is possible to apply -Werror only to some of the warnings and not to all of them? It would sound like a useful improvement.

No, I don't claim KDE is perfect. Especially the way the transition to KDE 4 is (not) being handled. (I don't mean within Debian, this is a KDE problem.) But beyond dumbing down the UI as even a very prominent Linux developer repeatedly commented on, Josselin Mouette just confirmed my decision to stay away from GNOME. Yes, there are other desktop environments and window managers, and I haven't done more than look at XFCE very briefly, but just now I'm quite happy with KDE 3.5, and am waiting for KDE 4 to become actually useable.

Given the recent brouhaha in Debian, and General Resolution regarding Lenny s Release policy as it relates to Firmware and Debian s Social Contract, which has led to the resignation of Manoj Srivastava from the position of Secretary for the Debian Project, I m reminded of the following passage from Gordon Dickson s Tactics of Mistakes (part of Dickson s Childe Cycle, in which he tells the story of the rise of the Dorsai):

No, said Cletus. I m trying to explain to you why I d never make an Exotic. In your calmness in the face of possible torture and the need to kill yourself, you were showing a particular form of ruthlessness. It was ruthlessness toward yourself but that s only the back side of the coin. You Exotics are essentially ruthless toward all men, because you re philosophers, and by and large, philosophers are ruthless people. Cletus! Mondar shook his head. Do you realize what you re saying? Of course, said Cletus, quietly. And you realize it as well as I do. The immediate teaching of philosophers may be gentle, but the theory behind their teaching is without compunction and that s why so much bloodshed and misery has always attended the paths of their followers, who claim to live by those teachings. More blood s been spilled by the militant adherents of prophets of change than by any other group of people down through the history of man.

The conflict between idealism and pragmatism is a very old one in the Free and Open Source Software Movement. At one end of the spectrum stands Richard Stallman, who has never compromised on issues regarding his vision of Software Freedom. Standing at various distances from this idealistic pole are various members of the Open Source Community. For example, in the mid-1990 s, I used to give presentations about Linux using Microsoft Powerpoint. There were those in the audience that would give me grief about using a non-free program such as MS Powerpoint, but my response was that I saw no difference between driving a car which had non-free firmware and using a non-free slide presentation program. I would prefer to use free office suite, but at the time, nothing approached the usability of Powerpoint, and while dual-booting into Windows was a pain, I could do a better job using Powerpoint than other tools, and I refused to handcap myself just to salve the sensibilities of those who felt very strongly about Free Software and who viewed the use of all non-Free Software as an ultimate evil that must be stamped out at all costs. It is the notion of Free Software as a philosophy, with no compromises, which has been the source of many of the disputes inside Debian. Consider, if you will, the first clause of the Debian Social Contract:

Debian will remain 100% free We provide the guidelines that we use to determine if a work is free in the document entitled The Debian Free Software Guidelines. We promise that the Debian system and all its components will be free according to these guidelines. We will support people who create or use both free and non-free works on Debian. We will never make the system require the use of a non-free component.

This clause has in it no room for compromise. Note the use of words such as 100% free and never make the system require the use of a non-free component (emphasis mine). In addition, the Debian Social Contract tends to be interpreted by Computer Programmers, who view such imperatives as constraints that must never be violated, under any circumstances. Unfortunately, the real world is rarely so cut-and-dried. Even the most basic injunctions, such as Thou shalt not kill have exceptions. Few people might agree with claims made by the U.S. Republican Party that the war in Iraq qualified as a Just War as defined by Thomas Aquinas, but rather more people might agree that the July 20, 1944 plot to assassinate Hitler would be considered justifiable. And most people would probably agree most of the actions undertaken by the Allied Soldiers on World War II battlefields that involved killing other soldiers would be considered a valid exception to the moral (and for those in the Judeo-Christian tradition, biblical) injunction, Thou shalt not kill . As another example, consider the novel and musical Les Mis rables, by Victor Hugo. One of the key themes of this story is whether or not Thou shalt not steal is an absolute or not. Ultimately, the police inspector Javert, who lived his whole life asserting that law (untempered by mercy, or any other human considerations) was more important than all else, drowns himself in the Seine when he realizes that his life s fundamental organizing principle was at odds with what was ultimately the Right Thing To Do. So if even the sixth and eighth commandments admit to exceptions, why is it that some Debian developers approach the first clause of the Debian Social Contract with a take-no-prisoners, no-exceptions policy? Especially given the fourth clause of the Debian Social contract:

Our priorities are our users and free software We will be guided by the needs of our users and the free software community. We will place their interests first in our priorities. We will support the needs of our users for operation in many different kinds of computing environments. We will not object to non-free works that are intended to be used on Debian systems, or attempt to charge a fee to people who create or use such works. We will allow others to create distributions containing both the Debian system and other works, without any fee from us. In furtherance of these goals, we will provide an integrated system of high-quality materials with no legal restrictions that would prevent such uses of the system.

This clause does not have the same sort of absolutist words as the first clause, so many Debian Developers have held that the needs of the users is defined by 100% free software . Others have not agreed with this interpretation but regardless of how needs of the users should be interpreted, the fact of the matter is, injuctions such as Thou shalt not kill are just as absolute and yet in the real world, we recognize that there are exceptions to such absolutes, apparently unyielding claims on our behavior. I personally believe that 100% free software is a wonderful aspirational goal, but in particular with regards to standards documents and firmware, there are other considerations that should be taken into account. People of good will may disagree about what those exceptions should be, but I think one thing that we should consider as even higher priority and with a greater claim on how we behave is the needs of our users and fellow developers as people. For those who claim Christianity as their religious tradition, Jesus once stated,

Thou shalt love the Lord thy God with all thy heart, and with all thy soul, and with all thy mind. This is the first and great commandment. And the second is like unto it: Thou shalt love thy neighbour as thyself. On these two commandments hang all the law and the prophets.

Even for those who do not claim Christianity as their religious tradition, most moral and ethical frameworks have some variant on the Golden Rule: Do unto others as you would have them do unto you . I would consider, for example, that the Golden Rule is at least a high priority claim on my behavior as the notion of free speech, and in many cases, it would be a higher priority claim. The recent controversy surrounding Josselin Mouette was started precisely because Joss has taken a something which is a good thing, namely Free Speech, and relegated it to a principle more important than all else, and claiming that any restraint on such a notion was equivalent to censorship. I think the same thing is true for free software, although it is a subtler trap. Philosophical claims than 100% free software as most important consideration is dangerously close to treating Free Software as the Object of Ultimate Concern or in religious terms, idolotry. For those who are religious, it s clear why this is a bad thing; for those who aren t if you are unwilling to worship a supernatural being, you may want to very carefully consider whether you are willing to take a philosophical construct and raise it to a position of commanding your highest allegiance to all else, including how you treat other people. Ultimately, I consider people to be more important than computers, hardware or software. So over time, while I may have had some disagreements with how Mark Shuttleworth has run Canonical Software and Ubuntu (but hey, he s the multimillionaire, and I m not), I have to give him props for Ubuntu s Code of Conduct. If Debian Developer took the some kind of Code of Conduct at least as seriously as the Social Contract, I think interactions between Debian Developers would be far more efficient, and in the end the project would be far more successful. This may, however, require lessening the importance of philosophical constructs such as Free Speech and Free Software, and perhaps becoming more pragmatic and more considerate towards one another.

For various reasons (which in the end boil down to lack of manpower), we are quite late in the process of packaging GNOME 2.24. (This is almost finished now, I ll keep you informed.) Which is why I may sound coming a bit late on noticing this one, but I was really speechless. The problem: session management has flaws Currently, a session manager uses XSMP (the X Session Management Protocol) to talk to applications. What it means is that for applications supporting this protocol, it is able to do more than simply starting and killing them: it will also remember their state, and offer them a way to shut down gracefully. However, XSMP is really a shitty protocol I won t explain why here, you will find tons of better explanations on the intarweb. The gnome-session developers, being quite aware of this issue, did what anyone interested enough would have done: they designed a new protocol, based on D-Bus, and implemented it. The new protocol is not considered stable yet, but it is simple, efficient and above all, reliable that s a giant leap forward. For this reason, I was very excited to see what gnome-session 2.24 would look like, since it brings major cleanups in the code. The solution: remove session management! When I first started it, it did not restore my saved session. I simply supposed that the format of the saved session had changed, and that writing a conversion tool would be in order. Wrong. Let s bring the session preferences: The UI of this dialog hasn t changed since 2.22. However, I do not resist the urge to show you the code behind the Remember Currently Running Applications button:

static void
on_save_session_clicked (GtkWidget           *widget,
                         GsmPropertiesDialog *dialog)
 
        g_debug ("Session saving is not implemented yet!");
 

As for the check box on top of it, it sets a GConf value that is never read anywhere. If you know the long term plans for GNOME, it makes sense: when gnome-shell replaces the panel and the window manager, it will also be responsible for starting the visible applications, while gnome-session will deal with what s happening behind the scenes. But gnome-shell is still far from ready, and you need something in the meantime for the basic requirements of a session manager! Backwards compawhat? The surprises don t stop here. I also noticed that logout was much faster instantaneous instead of the usual 2-3 seconds. The reason why logging out is this long currently is not because it takes long to kill applications; it s because the session manager kindly requests applications supporting XSMP to shut down before killing them. If a document isn t saved, an application will be able to prevent the logout process. Guess what? Now gnome-session completely ignores XSMP applications. Since it doesn t need them to register for saving the session, it also saves the time to ask them to close cleanly. The result is that you will see a lot of such dialogs: It s very nice to replace a flawed protocol ; and really, the new protocol goes in the correct direction. But let s be realistic, it s impossible to immediately port hundreds of applications to a new protocol without having a transition time during which both protocols are supported. You also need to consider your protocol as stable before asking other developers to port their applications. And to get it accepted, you need to standardize it; freedesktop.org would have been the correct body. (Currently, the protocol lies in the org.gnome namespace, not org.freedesktop.) Release management at its best Wait aren t there some distributions out there which already released stable versions with GNOME 2.24? The answer is yes. At least Ubuntu Intrepid and Fedora Core 10 ship with a session manager that:

• is unable to restore applications;
• kills applications without letting you save your work.

It s good to see such improvements on the session manager coming, and I m really thankful to the gnome-session developers to work on it. What I wonder is:

• How could it slip into a stable GNOME release?
• How could two major distributions let it slip into a so-called stable release?

It definitely looks like we re not the only ones who could improve our release management processes. So what? This is a very good example of a lack of big picture thinking. On one side, there is a brilliant design and its good implementation. On the other side, two major regressions from the user s point of view the kind of regressions that make people fly away. If there s one thing that I ve learned from working in IT, it s that you must often keep your brilliant designs as long-term goals. In the short term, you will run a bastardized version of your brilliant design that will make you cry; but it will work. When you need to talk to shitty applications or with shitty protocols, you need to write shitty code.

The Debian Python Modules Team is discussing which DVCS to switch to from SVN. Ondrej Certik asked how to generate a list of commiters to the team s repository, so I looked at it and got this:
emilio@saturno:~/deb/python-modules$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
865 piotr
609 morph
598 kov
532 bzed
388 pox
302 arnau
253 certik
216 shlomme
212 malex
175 hertzog
140 nslater
130 kobold
123 nijel
121 kitterma
106 bernat
99 kibi
87 varun
83 stratus
81 nobse
81 netzwurm
78 azatoth
76 mca
73 dottedmag
70 jluebbe
68 zack
68 cgalisteo
61 speijnik
61 odd_bloke
60 rganesan
55 kumanna
52 werner
50 haas
48 mejo
45 ucko
43 pabs
42 stew
42 luciano
41 mithrandi
40 wardi
36 gudjon
35 jandd
34 smcv
34 brettp
32 jenner
31 davidvilla
31 aurel32
30 rousseau
30 mtaylor
28 thomasbl
26 lool
25 gaspa
25 ffm
24 adn
22 jmalonzo
21 santiago
21 appaji
18 goedson
17 toadstool
17 sto
17 awen
16 mlizaur
16 akumar
15 nacho
14 smr
14 hanska
13 tviehmann
13 norsetto
13 mbaldessari
12 stone
12 sharky
11 rainct
11 fabrizio
10 lash
9 rodrigogc
9 pcc
9 miriam
9 madduck
9 ftlerror
8 pere
8 crschmidt
7 ncommander
7 myon
7 abuss
6 jwilk
6 bdrung
6 atehwa
5 kcoyner
5 catlee
5 andyp
4 vt
4 ross
4 osrevolution
4 lamby
4 baby
3 sez
3 joss
3 geole
2 rustybear
2 edmonds
2 astraw
2 ana
1 twerner
1 tincho
1 pochu
1 danderson
As it s likely that the Python Applications Packaging Team will switch too to the same DVCS at the same time, here are the numbers for its repo:

emilio@saturno:~/deb/python-apps$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
401 nijel
288 piotr
235 gothicx
159 pochu
76 nslater
69 kumanna
68 rainct
66 gilir
63 certik
52 vdanjean
52 bzed
46 dottedmag
41 stani
39 varun
37 kitterma
36 morph
35 odd_bloke
29 pcc
29 gudjon
28 appaji
25 thomasbl
24 arnau
20 sc
20 andyp
18 jalet
15 gerardo
14 eike
14 ana
13 dfiloni
11 tklauser
10 ryanakca
10 nxvl
10 akumar
8 sez
8 baby
6 catlee
4 osrevolution
4 cody-somerville
2 mithrandi
2 cjsmo
1 nenolod
1 ffm
Here I m the 4th most committer And while I was on it, I thought I could do the same for the GNOME and GStreamer teams:
emilio@saturno:~/deb/pkg-gnome$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
5357 lool
2701 joss
1633 slomo
1164 kov
825 seb128
622 jordi
621 jdassen
574 manphiz
335 sjoerd
298 mlang
296 netsnipe
291 grm
255 ross
236 ari
203 pochu
198 ondrej
190 he
180 kilian
176 alanbach
170 ftlerror
148 nobse
112 marco
87 jak
84 samm
78 rfrancoise
75 oysteigi
73 jsogo
65 svena
65 otavio
55 duck
54 jcurbo
53 zorglub
53 rtp
49 wasabi
49 giskard
42 tagoh
42 kartikm
40 gpastore
34 brad
32 robtaylor
31 xaiki
30 stratus
30 daf
26 johannes
24 sander-m
21 kk
19 bubulle
16 arnau
15 dodji
12 mbanck
11 ruoso
11 fpeters
11 dedu
11 christine
10 cpm
7 ember
7 drew
7 debotux
6 tico
6 emil
6 bradsmith
5 robster
5 carlosliu
4 rotty
4 diegoe
3 biebl
2 thibaut
2 ejad
1 naoliv
1 huats
1 gilir

emilio@saturno:~/deb/pkg-gstreamer$ svn log egrep "^r[0-9]+ cut -f2 -d sed s/-guest// sort uniq -c sort -n -r
891 lool
840 slomo
99 pnormand
69 sjoerd
27 seb128
21 manphiz
8 he
7 aquette
4 elmarco
1 fabian
Conclusions:
- Why do I have the full python-modules and pkg-gstreamer trees, if I have just one commit to DPMT, and don t even have commit access to the GStreamer team?
- If you don t want to seem like you have done less commits than you have actually done, don t change your alioth name when you become a DD (hint: pox-guest and piotr in python-modules are the same person)
- If the switch to a new VCS was based on a vote where you have one vote per commit, the top 3 commiters in pkg-gnome could win the vote if they chosed the same! For python-apps it s the 4 top commiters, and the 7 ones for python-modules. pkg-gstreamer is a bit special

during the ongoing avalanche of posts on Planet and on Debian mailing lists where you ask everyone to be friendly and considerate, you have so far:

• deliberately framed the discussion in a gender-oriented fashion to throw away unjustified accusations of sexism;
• inflated a 85-post long mudslinging thread with my name in the topic (which is the Google version of publicly throwing stones at people);
• vomited on people on an IT news site and helped the site spreading misinformation about the Project;
• shown your own frustration by trying to find hidden sexual references in messages you find offensive;
• and I m probably missing a lot since I m not reading all that crap.

Pretty please. What you mean is Go fuck yourself , but the way you are saying it is no more friendly and actually much more rude. If you meant Go fuck yourself , why not just say it?

• I would have felt better since it s much less insulting.
• You would have felt better since it s really a relief to say it frankly.
• Everyone else would have felt better since this would have ended the discussion instead of polluting the lists with useless wanking.

You are just lying to yourselves if you think your contributions to a flamewar are more friendly than others. As for those starting discussions on the community and on the code of conduct: do you want a community like Ubuntu where everyone can be scornful and prepare lousy tricks, but always preserving the appearances (thanks to a mandatory broomstick), or a community like the Linux kernel, where people say frankly what they think, even if what they think is I hope you were on crack while writing that ? I know which one I choose. I may disagree with their technical development model, but at least they know that a software community is not a group of friends. And that is a sign of maturity.

Now you know what to do.

Hint: it starts with Further and ends with Discussion .

Hey planet, it s been a very long time since I took my e-pen to write something down here, my work is taking pretty much all my time nowdays. Anyway, it seems that there is sort of a polemic rising here and there about RubyGems and its packaging philosophy. I d like to take that opportunity to contribute to the debate with the experience I had at Yoolink. Yes, we provide Ruby on Rails applications and are defacto dealing (or trying to) with Ruby and its gems. Wouter enlightened the main reason why it s such a mess to put into production a Rails app and to maintain it : the Ruby on Rails ecosystem is unstable. If you start writing your app, there are very big chances that when it gets mature for production mode, one or more of the Ruby libs you depend on will have a new version. And sadly, chances are there too that one of those libs will provide an API change. This can happen in a lot of places in a Rails app, because of its modular structure: plugins, gems or even Rails core upgrades (try to upgrade a real-working Rails app from 1.x to 2.x if you like tricky games). I agree with Joss when he said that Debian packages and Ruby gems are not designed for the same purpose, the latter are for a developer ecosystem and the first suitable for long-working production ecosystems. That s why setting up a complex Rails app in production is a nightmare : no Debian packages for all your Ruby needs on the first hand and API-unstable and hard-to-upgrade gems on the other hand. At Yoolink, the only working way we ve found to maintain in production our Rails apps is to freeze pretty much every Ruby-thing we can. Our production servers are then Rails/Ruby free (nothing installed system-wide) and the apps provides all their Ruby dependencies in their vendor/ directory. You can t do that for native gems but that works for 90% of a random Rails app s dependencies. To conclude, I d say that most of these issues come from the philosophy of the Ruby/Rails people : they don t fear to change anything they want from one release to another, just take a look at the gettext support in Rails 2.2 and you ll understand what I mean . It s like they don t even take in mind that people are now using their stuff, in real world, with customers relying on their apps. It s not a pet project anymore guys, if Rails want to remain the killer app it is, it will have to be someting stable and maintainable.